COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	Initial response to HAL.COM[POP,DBA]
C00005 00003	RHT 12 Sept-1974
C00008 ENDMK
C⊗;
Initial response to HAL.COM[POP,DBA]

RF 12-Sept-1974

Your desire for general user-defined data structures is a distant
hope for us, but at present we desperately need only scalars,
vectors, planes, frames, and transes.  We can see that for vision
work we will need more.  But we are not trying at the moment to make
a general purpose high-level language for the 11, merely what we know
we need for assembly.

You are right that we have two levels of language; one is the primary
manipulation language, and the other is an attempt at a very advanced
(for our present skill) problem description language.  We do not
intend that the former be a GPL in your sense; it is primarily a
manipulation language. The suggestion that the compiler be written in
GPL is absurd, since no manipulation is done during compilation, and
the object code is destined for the 11.  As for the PDL being of
confusing syntax, this is just not so.  The patterns for ASSERT are
of simple generality, and the VHL primitives all follow a
keyword-clause syntax which should be quite easy to use.  Confusion
can only arise in use of some of the ugly subpattern extractors and
compile-time variable manipulation.

You say that a monitor is not a proper part of the language.  This is
not so; it is a crucial part.  It is our means for specifying
periodic, scheduled interruptions of execution for the purpose of
examination of the state of the world.  It is essential for real-time
control with any programmable feedback whatsoever.

UNITS is merely a note to the compiler, necessitated by the fact that
people are not agreed as to the best way to measure quantities.  I
guess we might eventually extend the concept so the user can claim he
is working in rods and troy ounces, or whatever, but this is
currently a needless frill.

RHT 12 Sept-1974

I agree that assertions should actually be more structured than mere
token streams.  The "chunking" rules do provide some structure; whether
this is sufficient reamins to be seen.  There are a number of
problems as well as a number of possibilities in using parser
internal structures as assertion elements (as well as a number of
difficult problems in deciding when to resolve compile-time
conditionals involving planning values). One possibility is to
introduce a syntax like:

	ASSERT FACT (For taskxxx use method 
				[statement: 
					begin
					 move yellow to x;
				 end ])

This syntax is very ugly, and doubtless a better one can be found.
There is a very general difficulty with building parser internal
structures for fragments that occur out of context, unless a
bottom-up parsing technique is adopted.  It may very well turn out
that more "structured" assertions will be harder for a user than what
is provided now.  I do agree that this section could use some
additional design work; perhaps Mr. Anderson would care to make a
concrete proposal, rather than just a diatribe on the limitations of
the present design.

While it is true that HAL includes both manipulation control and
"very high level" primitives, I do not believe that it is quite
correct to say that these are totally separable entities.  (1) The
range of facilities provided is quite broad.  (2) A great deal of
mechanism sharing is necessary. (3) I strongly suspect that users
will want to use the whole range of facilities.  I.e., they will
specify detailed motions for some subtasks and use the high level
primitives for other subtasks.  The memo already includes some
discussion of the issues raised by all this; some specific comments
on that discussion might be very helpful.